A controller area network (CAN) protocol configuring a backbone network of a vehicle network is implemented by a CAN controller and a CAN transceiver.
Referring to FIG. 1, the CAN protocol includes a CAN controller 120 and a CAN transceiver 130. In addition, the CAN protocol is connected to a microcomputer (hereinafter, referred to as an MCU) 110. The CAN controller 120 has an internal buffer and determines whether a message received from the CAN transceiver 130 is valid and sends the message to the MCU 110. The CAN controller 120 sends data from the MCU 110 to the CAN transceiver 130.
The CAN transceiver 130 converts transmission/reception data received from a CAN bus or the MCU 110 into an electrical signal. The CAN transceiver 130 converts data received from the MCU 110 into data for CAN communication and converts data for CAN communication received from the CAN bus into data to be transmitted to the MCU 110.
The CAN transceiver 130 may have functions equal or similar to a general transceiver used for a vehicle. The CAN transceiver 130 operates in a power-on standby state, a standby state, a normal state, a doze state or a sleep state, which may be changed under control of the MCU 110.
The CAN transceiver 130 generates a CANH/CANL signal using two FETs. The two FETs include one P channel type MOSFET as shown in FIG. 2A and one N channel type MOSFET as shown in FIG. 2B.
The P-type element shown in FIG. 2A has low FET speed but the price of a driver thereof is cheap. In addition, the P-type element does not require a booster circuit and is implemented with ease. The N-type element shown in FIG. 2B has high FET speed but the price of a driver thereof is expensive. In addition, the N-type element requires a booster circuit and ease of implementation thereof is reduced.
Due to different ON/OFF speeds of the P-type element and the N-type element, the ON/OFF waveforms of CANH and CANL lines may be different. Therefore, it is not possible to accurately configure a bit time.